The Universal Serial Bus (USB) specification was originally released in 1996, updated in 1998, and enhanced for high speed data operations in 2000. USB originally allowed simple devices like keyboards, mice, and web-cameras, to be connected to complex hosts like personal computers (PCs) using cables up to 15′ in length, at up to 480 Mbps signaling speed. In addition, connected devices could be powered from the host.
USB is the most successful interconnect specification ever developed for consumer electronics (CE) as measured by the number of devices using USB. About 10 billion USB devices now exist, and USB is used for most CE products like personal computers, audio and video devices, MP3 players, mass storage, television sets, and satellite and cable decoders. USB is also used for professional electronics, test and measurement devices, personal health equipment, among many other types of electronic devices. Essentially any type of electronic device that requires the transfer and/or storage of data uses a USB interface. Various standalone apparatus easily connect using USB.
The success of USB has led to new and simpler types of hosts, as well as more complex multifunction devices. One such example includes a TV set as a host that can be used to show the movie recorded by a mobile phone. Or, a mobile phone that can be used as a host that can output the same video to a monitor. Mobile phones now account for 30-50% of the 2-3 billion USB devices that are currently shipped each year.
USB is also increasingly being used inside systems and devices. A typical example is to (permanently) connect, for instance, an integrated fingerprint reader and video camera in a laptop PC. This approach, however, is not without its problems.
First, standard USB signaling is not trivial to fully integrate in the complex system-on-chip (SoC; or an integrated chip) solutions made using today's advanced silicon processes. Therefore, the USB transceiver macro-cell interface (UTMI+) Low PinCount Interface (ULPI) specification was published in 2004 to allow the analog transceiver (“PHY” or physical interface/layer responsible for handling USB signaling) to be moved to a separate chip made in a different and more suitable silicon process than what is used to manufacture the digital SoC.
Second, standard USB signaling is not power efficient. This was not a major concern for use in desktop PCs or similar types of products. However, power efficiency is important in general in many other types of devices, and especially vital for portable devices. Minimizing power consumption means increasing battery life, longevity, and provides a better user experience.
As a result, the High Speed InterChip (HSIC) specification was released in 2007 to address the concerns of analog-versus-digital technologies, and power consumption. The HSIC specification describes how standard USB signaling can be replaced by HSIC signaling using a digital PHY. That is, instead of a separate analog transceiver, an integrated component, a digital transceiver, which is much more similar to the rest of the circuitry it is connected to, is used for USB interfaces within devices. This allows a power optimized connection of up to 4″ in length to be used between chips and modules inside a system with the digital HSIC transceiver integrated in the digital SoC. Apart from the electrical differences, HSIC and standard USB uses the same lower level and higher level USB protocols.
Because of the adoption and use of the HSIC specification, HSIC is increasingly being used in portable devices such as mobile phones. For example, one manner of using HSIC is to connect a wireless modem to the application processor in an advanced mobile phone. As discussed above, power optimization and integration are key factors in marketing successful products (i.e., small size, long battery life and enhanced user experience are key requirements). The HSIC modem and the application processor or host USB functionality is quite complex. An effective development, test and verification environments for HSIC is therefore mandatory for these products.
Unfortunately, HSIC signaling is not robust. Preparing the printed circuit board (PCB) for connection to test and verification equipment will affect HSIC signal integrity, sometimes to the extent that HSIC communications are no longer possible. The market for specialized HSIC test equipment is very small and in practice non-existent. Furthermore, as explained in greater detail below, standard USB analyzers cannot be used. This means effective development, test and verification of USB communications for products using HSIC has been, to this point in time, been virtually impossible.
It is useful to understand how high speed USB components are inter-connected and how standard USB communications are monitored to understand the problems with testing HSIC signals and the general inventive concept.
By way of example, a USB controller in a wireless modem has a Universal Transceiver Macrocell Interface (UTMI+) for connection to a USB transceiver. In the year 2000, most, if not all USB transceivers in commercial products were macro-cells and integrated on the same SoC as the USB controller.
A UTMI+ interface uses between 50 and 60 pins depending on which level of Plus-functionality is needed. As a result, UTMI+ is not very useful for external transceivers, as pin-count must be minimized for size, cost, and power reasons in the digital SoC. To connect to an external ULPI transceiver, a ULPI wrapper on the UTMI+ interface is added. The ULPI wrapper provides a means for reducing the pin count on the UTMI+ interface, yet still provides the same functionality.
In the figures described below, only the data paths are shown, and not the control paths. According to exemplary embodiments, the arrows in the figures indicate the general direction of data transfers.
FIG. 1 illustrates a block diagram of a standard USB device (USB device) 7 (comprising USB controller 2, ULPI wrapper 4 and ULPI PHY 6, among other components, not shown) connected to a standard USB host 8, with a USB analyzer 10 for debug attached to the interface between the USB host 8 and ULPI PHY 6.
It is useful to understand the basic concepts of a USB transaction: A USB transaction consists of token, data, and handshake packets. When USB host 8 has data to send to USB device 7, it will first send a token indicating that data is going follow. USB host 8 then sends the data. USB device 7 answers with a handshake to indicate that data was received. When USB host 8 wants to receive data from USB device 7, it sends a token indicating that data is expected. If USB device 7 has data to send, it sends it and USB host 8 answers with a handshake to indicate that data was received. If USB device 7 does not have data to send to USB host 8, USB device 7 returns a “no data” handshake and USB host 8 will request data sometime later. Thus, communications between USB host 8 and USB device 7 involves a series of token transmissions, exchanges of data, and handshakes to complete and verify the successful transfer of data.
Standard USB device 7 comprises USB controller 2, the output of which is a UTMI+ signal and is connected to ULPI wrapper 4, the output of which are ULPI signals. The purpose of ULPI wrapper 4 is to reduce the amount of signals being used to transmit and receive data from USB controller 2 and USB host 8. ULPI PHY (transceiver) 6 is also part of standard USB device 7 (as discussed above, it is physically separated from the other components of standard USB device 7, as it is comprised of analog circuitry, which is very difficult to integrate with digital circuitry on a single integrated circuit; this is why ULPI PHY is shown enclosed by the dashed lines within standard USB device 7), and receives the ULPI signals output by ULPI wrapper 4, and transmits them to USB host 8 through USB analyzer 10, and conversely receives USB signals from USB host 8 and directs them to the ULPI wrapper to be converted to UTMI+ form to be received and processed by USB controller 2.
USB analyzer 10 is a passive “sniffer” type device. Some implementations use a high impedance pass-through mode allowing connection of USB analyzer 10 with more than one standard USB cable 14. This kind of connection approach has been used since the first USB analyzers were developed together with the USB specifications. USB signals from standard USB device 7 are transmitted by ULPI PHY 6 through one cable, 14a, to USB analyzer 10. At USB analyzer 10, high impedance tap-off 42 can be seen connected to the short trace that connects a first connector and a second connector at USB analyzer 10. The very short high impedance tap off 42 has virtually no effect on the substantially longer low impedance USB signal run that includes USB cable 14a and a second cable, 14b. Here, the second connector at USB analyzer 10 is connected to USB host 8 via second USB cable 14b. 
All USB traffic, regardless of direction from USB host 8 to USB device 7, or from USB device 7 to USB host 8, can be captured by USB analyzer 10 and transferred to USB analyzer host 12 for e.g. pre-processing and display. Powerful software tools, coupled with sophisticated hardware designs, have been developed by the industry and included in USB analyzers to provide for highly functional monitoring and error detection. USB analyzer 10 can be set up to filter and trigger on certain conditions, including various types of errors and certain transactions, and only capture traffic that is relevant for the problem to be investigated. USB analyzer 10 might also output a trigger signal when a certain condition is met. Cross-triggering with existing software development tools on USB host 8 and/or USB device 7 allows the capture of a sequence of processor instructions that leads to a USB error. The sequence that leads to the error can then be investigated.
FIG. 2 illustrates a block diagram of first modified USB device 9 with selectable ULPI or HSIC capability, connectable to either standard USB host 8 or standard HSIC host 18. First modified USB device 9 comprises USB controller 2, ULPI/HSIC switch/mux 20, ULPI wrapper 4, ULPI PHY 6, and HSIC PHY 16. USB controller 2, the output of which is a UTMI+ signal, is connected to ULPI/HSIC switch/mux (switch/mux) 20. The UTMI+ signals output from USB controller 2 can therefore be input to HSIC PHY (a transceiver) 16 or to ULPI wrapper 4. The output of ULPI wrapper 4 is input to ULPI PHY 6, as with standard USB device 7. HSIC PHY 16 transmits and receives signals to/from HSIC host 18 via HSIC cable 34, and ULPI PHY transmits and receives signals to/from USB host 8 via USB cable 14.
Some SoCs have the capability to use either standard USB or HSIC signaling, as shown in FIG. 2. When an internal HSIC transceiver (HSIC PHY 16) is integrated on the same SoC, as shown in FIG. 2, switch/mux 20 is used to connect either HSIC PHY 16 to USB controller 2, or ULPI wrapper 4 to USB controller 2. Simultaneous operation of both HSIC and standard USB is not possible. The output of switch/mux 20 is normally selected based on the product the SoC is used in. Furthermore, selecting USB or HSIC on a session-by-session basis depending on the use and/or application is also possible.
When developing the HSIC specification, it was believed that advanced HSIC debug and test would not be needed, as existing USB software, protocols, and applications would be reused. However this is not always feasible due to the different requirements and capabilities between an embedded host, as exemplified by a mobile phone application processor, and a non-embedded USB host, as exemplified by a personal computer.
FIG. 3 illustrates a block diagram of second modified USB device 11 (with some components omitted for the dual purposes of clarity and brevity). The USB device 11 is connected to a standard HSIC host 18 via a proposed HSIC analyzer 22. The HSIC analyzer 22 is furthermore connected to HSIC analyzer host 24 for debug. It would appear to one of ordinary skill in the art that, in accordance with the configuration shown in FIG. 1, a similar test set-up would work in a fashion similar to that shown in FIG. 1. However it has been found that the configuration shown in FIG. 2 does not work. It has been determined that even preparing for an HSIC tap-off to HSIC analyzer 22 will interfere with HSIC communications. Connecting HSIC analyzer 22 to the circuit shown in FIG. 3 often interferes to the extent that HSIC communication fails. There are several reasons why there is such difficulty in testing HSIC communications. The most significant reason is that when the specification was developed for HSIC, it was very inclusive and broad, to allow for significant flexibility in manufacturing SoCs to include HSIC capabilities. Unfortunately, this had the unintended consequence of making it very difficult, and therefore expensive, to adequately design test equipment. In effect, because there is so much discretion in designing the HSIC communications interface, a test equipment manufacturer would have to almost know the exact specifications of the equipment under test. That would make it prohibitively expensive to design and manufacture the test equipment, as the test equipment manufacturer would not know how many other possible customers are using the same or similar specifications. Consequently, there is virtually no affordable HSIC test equipment capable of testing all HSIC communication interfaces. FIG. 4 illustrates a block diagram of third modified USB device 11 connected to standard HSIC host 18, in a setup similar to that shown in FIG. 3, with HSIC analyzer 22 for debug attached to between HSIC host 18 and HSIC PHY 16. In the configuration shown in FIG. 4, however, HSIC host 18 is connected to HSIC PHY 16 via a very short printed circuit board trace (with a length “I1”), and external HSIC analyzer 22 is connected to HSIC host 18 and HSIC PHY 16 via a very long USB interconnect 14b (with a length I2, typically such that I2>>I1). The influence of the “tap-off” 14b is significant in that it is very long, and a high-impedance connection. The energy that is transmitted from either HSIC PHY 16 or HSIC host 18 is reduced due to reflections that will occur at HSIC analyzer 22 resulting from the substantial differences in impedance between the much longer tap off 14b and the shorter (lower impedance) printed circuit board interconnect 14a. These reflections will introduce distortions in the HSIC signals transmitted between HSIC PHY 16 and HSIC host 18.
Not being able to test and debug HSIC communication has been found to be a major problem for HSIC product development and means that further development and verification of HSIC products are virtually impossible. Accordingly, it would be desirable to provide a method and apparatus to facilitate monitoring and protocol analysis of HSIC USB signaling without connecting to and thus compromising HSIC signal integrity.